A transaction processing system typically includes one or more resource managers for coordinating the processing of data (e.g. one or more queue managers in a messaging system). There are certain times in the processing of such data that the data will be of uncertain status (state) (e.g. an update/insert/delete request may be pending completion of a unit of work such as a transaction (commit/abort)). Data of uncertain status is typically invisible to all transactions apart from the one from which the data was modified. However this is intentional since it is considered dangerous for other transactions to have access to data whose status has been modified but has not yet been finalized by the transaction.
One example of a problem that arises as a result of data being of uncertain status is “the lost message” problem. FIG. 1 shows a much simplified example of a typical messaging system (e.g. WEBSPHERE ® MQ available from IBM ® Corporation (WEBSPHERE AND IBM are trademarks of International Business Machines Corporation in the United States, other countries, or both). Application 10 puts messages to queue manager 1 for transmission, via queue managers 2 and 3, to application 20. At queue manager 1, each message is received and placed on a transmit queue (XQ) 30 for transmission to queue manager 2. Mover 95 removes each message from XQ 30 and transmits them across channel 90 to queue manager 2, where such messages again get forwarded by mover code to XQ 40 and finally onto XQ 50. At XQ 50 messages are removed for processing by application 20. By way of example, application 20 may use such messages to update a database 80.
Occasionally such messages may fail to reach their destination. In which case the putting application 10 might not receive (within an acceptable time period) an acknowledgment that its message has been properly delivered to application 20. Consequently application 10 may alert system management software (not shown) to the possibility that there is a problem. Such software will typically then scour the route that the lost message should have followed looking for it. The lost message could be in any number of places—e.g. a dead letter queue 70 on any one of queue managers 1, 2 or 3. Alternatively the message may be on an XQ in an uncertain status (this may, for example, be the case if a request is pending or if a channel 90 fails in the middle of a transmit operation). If the latter is true, the message will be invisible to the system management software—in which case, such software will not find the message.
Since such uncertain messages do not exist as far as the system management software is concerned, there is a danger that they may never be found. For example an administrator may take the decision not to restore a broker transmission channel but to begin transmitting messages via a different queue manager (e.g. queue manager 4)—in which case, a message with an uncertain status may never reach its destination.
In another example, an application may start a transaction with a transaction coordinator and “get” a message from a queue manager in order to update a database. In this example, the transaction coordinator is using two-phase commit protocol. The message is got by the application which then accordingly updates the database and requests the transaction to commit. Both resource managers involved (i.e.: the queue manager and the database manager) are then asked to “prepare”. Once the queue manager has reached “prepared” state the message goes indoubt until the transaction is committed or backed out. If the transaction is committed the database update is finalized and the message is deleted from the queue, whereas if the transaction is backed out then the database update is aborted and the message remains on the queue. Before the message goes “indoubt”, the message is inprocess and it is permissible (though not always desirable) for the transaction coordinator or either resource manager to unilaterally decide that the transaction must be backed out. However, both of the resource managers reach “prepared” state, both are under contract to complete the transaction, and cannot unilaterally decide to commit or back out independently from the transaction coordinator. The message is in an uncertain state both before and after going “indoubt”; but once it is “indoubt” it is impossible to resolve this uncertainty until the queue manager is directed to complete (commit or back out) by the transaction coordinator. However, in a transaction, between a given resource manager going “indoubt” and being directed to complete, all other resource managers involved in the transaction must be contacted by the transaction coordinator. As a result if the transaction involves many resource managers this can take a very long time. Whether the message is inprocess or indoubt, it is still uncertain, and there are still two potential ‘final’ states depending on the transaction outcome.
There are other problems involved in reading records in a database (whether or not a messaging system is being used). There are various options for handling the reading of locked records:                i) Wait until record is unlocked—this is the standard option used by databases;        ii) Dirty read—read the record even though it is locked. This is used by databases where ‘low quality’ information is adequate. (Not all databases use the same conventions for dirty read, for example some will show the result of an update by returning the value of a record prior to the update, and some will return the value of a record as it will be if the update is successful);        iii) Skip locked. Skip over the locked record as if were not there, and return the next appropriate record (if available).        
These all have disadvantages: option i) can lock out an application for a long time, and cause unnecessary deadlocks. This option is nevertheless necessary where highest quality database data and strict ordering of records is required. Option iii) goes to the other extreme from dirty read—it gives the application no indication even of the existence of such records. Option ii) avoids deadlocks and does not “hide” records, but it may provide incorrect data without the application even being aware. Nevertheless option ii) it is a useful option which hitherto has been restricted in its use due to the aforementioned disadvantage.